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(57) Abstract: The present invention provides a system for creating an application software environment without changing an 
operating system of a client computer, the system comprising an ojjeraling system abstraction and protection layer, wherein said 
abstraction and protection layer is interposed between a running software application and said operating system, whereby a virtual 
environment in which an application may run is provided and application level interactions are substantially removed. Preferably, 
any changes directly to the operating system are selectively made within the context of the running application and the abstraction 
and protection layer dynamically changes the virtual environment according to administrative settings. Additionally, in certain em- 
bodiments, the system continually monitors the use of shared system resources and acts as a service to apply and remove changes 
to system components. The present thus invention defines an "Operating System Guard." These components cover the protection 
semantics required by DLLs and other shared library code as well as system device drivers, fonts, registries and other configuration 
items, files, and environment variables. 
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OPERATING SYSTEM ABSIRACHON ANB PROTECTION LAYER 

This application is a contiimatiQii-in-part of U.S. Patent Application No. 

09/456,181 ^ the entirety of wliich is incorporated herein by reference as if fiilly 

setfortk 

The present invention relates to conaputer software^ and more particularly to 
operating system software. 

BACK6ROl}NI> OF THE INVENTION 

In many environm^its^ hfut paitioilarly in enviroooments ^ere an applicatian is 
delivered via a network, the niDStin?)oitant feature is an ability to ran applications on the fly, 
without a con^lex installation. Typicany,incertampriorartsystenis, great pains were taken 
to modify a client system to appear as if a program was installed, or to actualty install the 
software itself and then back ont these modifications to restore the origmal configuration. Si 
doing this, muhaple problems present themselves: conflicts between an application and the 
con5)uter*s current configuration, mult^le mstances of the same or difiEerent applicationsi, 
complexity of the back out process requires an application to be put through a ligomus process 
to ensure all of its modifications can be accounted for, and the use of diared files and system 
con^onmts by malt^)le applications complicates back out and the installation process. 
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SDMMARY OF THE INVENTION 



The present nxvention provides a system for creating an application software 
environmeiit whiiout changing an operatmg system of a client coiqpiiter, the system 
con;>rising an operating system abstraction and protection layer, wherein said abstraction 
and protection layer is ialerposed1>etween a running software application and said 
operatmg system, whereby a virtual environment in which an application may run is 
provided and application level interactions are substantially removed. Preferably, any 
changes directly to the operating system are selectively made witliin the context of tilie 
rmming application and the abstraction and protection layer dynamically changes the 
virtual environment according to administrative settinjgs. Additionally, in certain 
embodiments, the system continually monitors the use of Glared system resources and 
acts as a service to apply and remove changes to system con^onents. 

Thus, for exanqple, in embodiments wiflbin Windows-based operating systems, 
and wherein all operations to the Windows Registry are through the Win32 API, flie 
system preferably provides a means for hookmg fimctions, whereby each time said 
functions are invoked another function or application intercepts the call, and the system 
most preferably hooks each appropriate API fimction to service a request Aether made 
by an application run ftom a server or if made by an application against a configuration 
key being actively managed 

In other preferred embodiments of the present invention, additional functionality 
is provided, such as those embodiments wherein the operating system abstraction and 
protection layer manages the integration of multiple instances of an application by 
recognizing how many instances of an application are running, and in such embodiments 
most preferably it also avoids making changes on startup and shutdovsoi unless there is 
only one application in^ance running. In this embodiment it is also possible to support 
muhi-us^r operating systems in which nxultiple instances of an application can be running 
on behalf of different users. 
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Thus, the operating system abstracdon and protecdon layer presents an 
environment to an application that appears to be an installation environinent without 
petfoitniag an installation, whereby a '^seudo installation" is created in which all of the 
settings are brought into a virtual environment at the time the application rmis. Or in the 
case of an installed application, act^ to dynamically nuxHfy the behavior of the 
application at mn-time. Preferred embodiments provide a means for preventing 
information on the diwt conq^uter from interfering or modifying the behavior of an 
appfication, and most preferably provide a means for dynamically changing the virtual 
environment according to admini^xatrve settings. As mentioned above, in certain 
embodiments it will be possible to have more than one instance of a single sojSware 
application nnming 00 the same client computer, even if it was not origmally authored to 
do. so. In sudi embodiments^ shared, controlled contexts are provided in yAdch at least 
two of said instances of a single application share one or more virtual settings. 

BRIEF DESCRimON OF TBE DRAWINGS 

FIG. 1 is a block diagram sdiem^ showing ibs relative Tda&mstup of the present 
invention, an operating system and a software application; 

HG. 2 is a block diagram schematic shoudng 

PIG. 3 is a block diagram sdiematic showing 

HG. 4 is a bloc^ dmgram schematic showmg 

DETAILED DESCRIPTION OF TBE PREFERRED EMBODIMENTS 

Referring now to FIG. 1, there is illastrated a block diagram schematic showmg the 
relative relationship of the present invention, an opei:ating system aiid a software appQcation. 
Preferred embodiments of the present invention provide an opeirating system abstraction and 
protection layer 100 doiommated an 'X)perating System Guard.** firtemally, many operating 
systems 10 provide fkvUt domains to protect applications 50 fiom affecting each other vHxesa 
rusL However, shared system resources and many other operating system features allow this 
protection domaia to be corcpromised. An operating system abstraction and protection layer 
100 will provide an additional, programnaatically controlled barrier between applications 50 to 
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Temove most appUcatiaii level iitteiactiQiis. IH^osed between fhe application 50 and operating 
system 10 tbe operating system abstraction and protection layer 100 selectively allows 
dianges directly to the operating sy^em 10, versos containing the change within the context of 
the ninmng appKcatioa For one 6xaxz9>le, in Windows-based systems, all operatioaos to the 
Windows Registry are typically done timmgh the Wm32 API As explained below, system 
fiincjtions like QoeiyRegEx and GetProfOieStdng can be hooked so that eadi time tiiey are 
invoked, anoth^ fimction or plication intercq>ts the call The Operating System Guard 100 
of the present invention VinU hook each appropdate API fimction to service the request, if 
made by an applicaticm bemg activdy managed or if made by an appfication against a 
configuration item bdngacttvefynoanaged. Iathi5way,inxless^lickty configured to do so, 
the present invention can create the appficatK)ii envinmment wdhout making any actual 
changes to the end-us^s system Also, any modifications made at run-time by the 
applicaticni can be perasted or removed eaaly. 

As used herein the tenn "Operating System Guard" defines a layer between a 
running application and tiie operating system of a target conq)Uter or client computer that 
provides a virtual environment in which an application may run. This virtual 
environment has several pinposes. First, it prevents a running application from making 
changes to the client computer. If an application attenq)ts to change underlying operating 
system settings of a client con5)uter, such settmgs are protected and only ^^de" in the 
virtual environment For exanqple, if an application atte2i5)ts to change the version of a 
shared object like MSVCRTJ)LL, this change is localized to the application and the code 
resident on the client computer is left imtouched. 

Second, the invention presents an environment to a runidng application that 
appears to be an installation environment without performing an installation, and is thus a 
'"pseudo installation'* or ^'installation-like." All of the settings are brought into a virtual 
environment at the time the application being served runs, or just-iu-time when the 
application needs the particular setting. For example, if a conq)uter program such as 
Adob^ Photoshop® expects to see a set of Windows Registry entries under 
HKEYJLOCAL_MACHnflS\Software\Adobe and they are not tiiere on the client 
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coniputer smce Photo^op was never installed, a system made in aocordAnce with this 
aspect of the present invention Avill *'show" those xegistry entries to the Photoshop 
progranuning code eTcactly as if they were resident on the client computer. 

Nto, the iavention prevents information that may exist on the di^tAisers • 
machine from interfering with or modifymg the behavior of an application. For eixmple, 
if the user has aheady existing registry entries under: 

HKEYJLOCAL_MAanNmSofhvare\^^ 
for an older version of Photoshop, bnt now wishes to operate a newer version, these 
entries can be hidden from the new ^plication to prevent conJSictsl 

FmaUy, the present invention unlocks application behavior that may not exist as 
the application is currently written. It does this through the ability to dynamically change 
the virtual environment according to admfaiistrative settings. For exan^le, in a typical, 
instance of an enterprise software application, a client application may expect to read a 
setting for the address of the database to which the user should connect from a setting in 
the registry. Because this registry key is often stored in HKEYJLOCALJMACHINE, the 
setting is global fox the entire client conputer. A user can only connect to one database 
without reinstalling the client, or knowing how to modify this registry key, and doing so 
each time they wish to run the applicatiozt However, by ingjlementing the present 
-invention, two instances of the application may. now run on the same client computer, 
each connecting to a different database. 



CONTEXTS 

In providing this iimctionah'ty, each application is able to iun in a private context 
within the system. To the application, it has its own private view ofwhat the system 
looks Jike and its behavior. The present invention provides this by its inherent nature. 
Referring to FIG. 2, two separate applications 52,54, or two instances of the same 
application (50 illustrated in FIG. 1), can be provided private contexts in which they will 
appear to have separate or diGfering copies of system services, configuration and data. In 
the pr^erred embodiment, this is the default behavior of the system. 
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By exteadkg this concept, the Operating System Ooard 100 of the present 
invention can also provide sh^ed, controlled contexts in which two or more applications 
52,54 can share some or all of their virtual settings. This is inqioitaiat for application 
suites such as Microsofi Office, or for appfications diat peifomi dififerendy in the 
presence of other appfications. For exan^le, many applications use Microsofi Word as 
anengbefor doing ^foiIM^ge or document creation fimctional^ The applicatidn 
must know about the installation or presence of Word and be able to tap into its 
fiinctions. In the preferred embodiment, two instances of the same application will ^are 
a snigle context by default, while two separate applications will maintain private 
contexts. Referring to FIG. 3, the two applications 52,54 can run while the Operatmg 
System Guard 100 provides a shared view of the available system resources. 

msiGN 

As iUustrated in FIG. 4, the Operating System Guard is coii5)rised of the 
bllowing subsystems: core 102, configuration manager 104, file manager 106, shared 
ibject manager 108, device sianager 110, font manager 112, process mianager 120, 
process enviroimient manager 114, loader 116, and recovery manager 118. With the 
xception of the core 102, the process manager 120, and the loader 116, all other 
ubsystems are elements of the Virtualization System described in further detail below, 
the core 1 02 is primarily responsible for managmg applications and their context as 
lefined by the configuration files. 

The process manager 120 provided by the Operating System Guard allows the 
jore 102 to be informed of any process or thread event that may be of interest. It also 
provides an abstraction layer to the operating system-dependent implementations for 
aanaging a process space and handling thread processing. Processes may be grouped 
ogether into application bundles. An application bundle is a group of processes vMch all 
hare their virtual resources with each other. For example, Microspfl Word and Microsoft 
*^cel may want to share the virtual registry and virtual file system to be able to work 
ogether 'as an application suite. The process manager 120 calls these application bimdles 
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"applications''. The informatioii about an application exists until the process manager 120 
is told to release the application. If another process needs to be loaded into the application 
bundle, it may do so as long as the application has not been released. 

Hie loader subsystem 1 1 6 of the present invention is used to allow virtoal 
environments to be transfetred into and out of the running system. Each of the 
Vhtualization Subsystems is capable of serializing its configuration for the loader 1 16, 
and retrieving it through the reverse process. In addition, the loader 116 is capable of 
staged loading/unloading and combining the results of individual stages into one single 
environment desmptioa 

REGISTRY AND CONFE611RATION 

^jiplications require varying amounts of configuration information to operate 
prop^ly. Anywhere firom zero to thousands of configuration records exist for which an 
application can read its configuration On Windows, there are two common places for 
configuration inJfonnation, the Windows Registry and system level iiiitialization files 
traijniandsystem.ini In addition, the \WINDOWS\SYSTEM directory is a common 
place for applications to write application qyecific configuration or initialization files. 
A|)plications will also use configuration or data files in their local application directories 
to store additional configuration information. Often this information is difiScult to deal 
with, as it is in a proprietary fiumat. On platforms other than Windows, there is no 
equivalent of the Registry, but common directories exist for configuration informatioa X 
\Wndows has an app-defauhs directory. Macmtosh has the System Folder, and other 
operating systems will have corresponding elements. Jt is inqportant to note that on most 
UNIX syst^sns, each individnal application 52,54 will most often store its own 
configuration 152,154 locally, as seen in FIG. 2. 

The present invention, ia one embodiment, includes a virtual Windows Registry 
conq>onent, which wiU provide a fiiQ function registry to an application, but prevent 
modification to the underlying system registry. All keys that an application expects to 
access will be present, but may only exist in the virtual registry. In this way, the 
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Operating System Guard 100 of the present invention and the Windows Registiy form a 
two-stage process lot accessing the registry. If an application needs access to a key, it 
win qaery the Registry, llie Operatmg System Guard wiU respond with the key and its 
vahieifit knows it CMberwise^d; wiU.aHow the request to pass through to the Wi^^ 
Registry. If an attempt is made to modify the value, the Operating System Guard will 
aSow the modification to occur to itself only. The next time the application accesses tiie 
key, it will be present in the Qperatmg System Guard and the request will not flow 
through to the real Registry, leaving it untoudied. 

The keys that the Operating System Guard uses are specified in three separate 
sections. These Operating System Guard keys are specified as commands in these 
sections to modify an existing key, delete the presence of a key, or add a new key to the 
registry. In this way, the virtual registry can appear exactly as the system intends. This is 
in^ortant as the presence or absence of a key can be as inq)ortant as the actual value of 
the key. 

In the preferred embodiment, the Operating System Guard first loads a data file 
that contains basic registry entries for the application. Then a second data file is loaded 
that contains the user's preferences. Finally, the Operating System Guard can optionally 
load a set of keys that include policy items that the user is not allowed to override. The 
three files load on top of each other with duplicate items in each file overriding items in 
the file before it. The first time a user runs an application, the second data file will not 
exist because there will be no user-specific information, only application defaults. After 
each session, though, the Operating System Guard will save the user's changes, 
g^erating that second data file for use in fiiture sessions. 

Configuration files can be modified in two ways. First, the file can be edited 
directly by an application. In this scenario, the Operating System Guard File subsystem 
described below will address the modification made to the file. Second, in the preferred 
embodiment, an application can call the Windows API family of calls GetProfileStdng, 
WriteProfUeStimg, or others to modify these files. Jh this case, the QperatiDg System 
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Guard of the present inveaitioiL peifbmis exactfy as described above intercepting these 
calls and servicing them fiom within. 

SHARED OBJECTS 

Many coi]q>onents used by operating syst^ns and tunning applications are shared 
across several appfications or instances. In general, this is a good idea. B saves disk 
space, not requiring many copies of the same file. It also provides the ability for 
operating system vendors and third parties to create and distribute libraries of commonly 
used code. On the Windows platform. Dynamic Link Libraries, DLLs, are often shared 
within and across applications. On other platforms, the problem is the same. On the 
Macintosh, INTrs and other system components are loaded for applications. These 
conoponents can have many versions, of ^^hich only one is used at a time. On UNDC 
systems, dynamic shared objects, e.g., "so" library files, are xised by applications to 
speed load time, save disk space, and for other reasons. Many programs use the de&ult 
"libc.so." However, this library file is typically a symbolic link to some version of itself 
such as Ubc.so.3. inpractice, this feature has created havoc. Tliese shared coniponents 
have often gone through revision, with many versions of the same con^onent available to 
be installed Application authors have found then: software to work with potentially only 
one or some of the versions of the shared conq>onent. Thus, in practice, applications 
typically install the version they desire, overwriting other present versions. This 
potentially causes de&ults in other applications running on a system. 

On Windows 98, Windows 2000, Microsoft has created the Windows Protected 
File System (WPFS)-to allow system administrators to create a file called 
XXXX.LOCAL in the base directory of an application, where XXXX is the executable 
file name without the extension. This causes the Windows Loader to alter its method of 
resolving path references during LoadLibrary executions. This, however, is not sufBcient 
to cpnqiletely solve the problem. First, setting up the XXXX file is left to the knowledge 
of the system administrator, vMch varies widely. Second, a component version must 
undergo a rewiad back to the original, then install this cong)onent in the local directory, 
and then create the ^\LOCAL" file. This is not a straightforward process for any but the 
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most basic conq)Qiieiits placed in WIND0WS\SYSIE1V1 Aliso, this solutian does not 
cover all of the needed functionality* Dming Loadlibraiy, Windows uses difieieiit path 
resolution semantics dqiending on i^etheir the con^Qnent was resolved as a result of an 
e7q)licit or iniplicit LoadIibrary,.and also whether a Reg^istry Key exists indicating diat it 
is a named, or.well-biown^ DLL In this case, the LoadLifaraty call will always resolve 
to the Wn«)OWS\SYSTEM directory. 

DLLs and other shared coii^oneots also retain reference count semantics to 
ensure that a conoponent is not touched unless no nnnung applications refer to it. Jsk 
practice, onfy applications from the operating system vendor and the operating system 
itself have done a good job of obeying this protocol 

As a general role, it is desired to have a shared object always resolve to the 
correct con^onent. To provide this functionality it is required to understand the version 
of a component, or range of ver^ons^ that an application is able to fimction with. Then, 
when the application is to be run, the present invention should ensure that the conq^onent 
is resolved correctly. Jt is acceptable, in the present invention, to automate the use of 
WPFS or other operating system provided capability, if deared. In this case, it is 
neces5arytodetectneededco]iQ>Gnentsandplacelhemin the local £le system. This is 
more complex than just watching installation, as an mstaUation program will often not 
install a component if the required one is already there. 

It is destred to identify a method to ensure that named objects are also loaded 
correctly. On the Windows platform, MSVCRT.DLL is a significant culprit within this 
problem area. IfniuMple versions ofthis object are inaintained, the aforementioned 
Registry key can be dynamically changed, allowing the Loadlibrary fimction to resolve 
the correct coirponent version. Another reasonable method of ensuring correct 
con^onent loading is the dynamic editing of a process environment to use a valid search 
path. This search path will ensure tiiat a local con9)onent is resolved before -a system 
wide coiz:ponent. Another possible method for resolution of the correct shared object is 
through the use of symbolic links. A Sfymbolic link can be made for a shared conoponent, 
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vMdi is resolved at xun-time by the con^uter's file system to the needed coiqpQnent 
Finally, tiie actual opeai/read/close requests for infinmation from a shared object's fUe 
can be intercepted by &e present invention and respcmded to dyoanxically fi>r tbe correct 
ver^on of the file which may exist on Die local system or within the invention's 
subsystems. 

Several fecial forms exist. On the Windows platform, OLE, ODBC, MDXc, . 
as wen as a mmiber of other vendor specific con^onents^ are written to be diared 
globally among several or all running processes, in the case of OLE, going as far as 
sharing data and memory space between s^arate proc^ses. OLE prevents more than 
one copy of itself running at a time, as do many of these components. OLE also has 
many bugs and features lequinng a specific version to be loaded for a specific 
application. Bi the present invention, an application is able to load whatever version of 
OLE is required, still enabling the shared semantics with other conq)onents \xm.g the 
same version of OLE. 

In general, unless ^edfically configured as such, shared objects shoiddbe loaded 
privately to easme conflict prevention. Nothing about the method used to allow a 
cortq)onent to be loaded privately should prevent it firoin being unloaded cleanly or 
coaectly loading Sot another software application, \>v4ether being actively managed by 
the Qperating System Guard or not. In addition, if the system crashes it is required to 
recover firom this crash to a clean state, not having overwritten or modified the 
underlying operating system. 

fILES 

Many applications xise data files withia the application to store configuration 
entries or other application data. The present invention provides a virtual file system 
much like the virtual registry described above. Before the application starts, the present 
invention can load a list of file system changes, including files to hide and files to add to 
the virtual environment or files to redirect to another within the virtual environment. 
Whenever the application accesses or modifies any file% the Operatmg System Guard 
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checks if the file must he redirected, and if so, in the preferred emhodiment redirects the 
request to a location specified in the Operating System Guard configuration. 



If an appfication tries to create a new file or open an existing file for wdting on a 
user's local drive, the Operating System Guard must ensure that the file is actually 
created or modified in the redirected location. If the application is reloaded at a later time^ 
this file mapping must be reloaded into the Operating System Guard virtual environment 
When the request is to modify an existing file, which resides on a user's local drive, the 
Operating System Guard must copy the fiSe in question to tiie redirection pomt before 
continuing with the request. The redirected files may not be of the same name as the 
original file to ensure safe mapping of file paths. la the preferred embodiment, INI files 
arehandledinthis way to offer maxinnun system security while allowing maxmsnm 
application con:;>atibility. . 

The preseat invention is particularly iisefiil for applications delivered ov&c a 
network. Ja such in^lementations it is important to understand that software applications 
are made pf several kinds of data, where the bulk of the files a software appfication uses 
are most preferably mounted on a separate logical drive. Configuration, including both 
file based and registiy based, can be user specific and system wide. The appfication 
defivery system used should mark each file fi>r vsduch of these types any file is. This 
information provides hints to fhe Operating System Guard system to act on appropriate^. 

DEVICE DRIVERS 

Many appfications use device drivers or other operating system, level software to 
implement some of its fimctions such as hardware support or low level interactions 
directly with the operating system Bi the present mvention, fhe Operating System Guard 
will provide the capability of dynamically, and as possible private^, adding and 
removing these con9>ohents to an application's virtual environment:. 

Many device drivers are built to be dynamically loadable. If at all possible, it is 
the preferred embodiment to load all device drivers dynamically. If a device driver 
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requires static load at boot time, Ae user must be presented with this Jbiowledge before 
running the application. Once the system has rebooted, the application should continue 
from where it left off However, a large percentage of device drivers are not dynamically 
miloadable. Although it is preferred to dynamicalfy unload the driver, if this cannot be 
accoinplished the driver will be marked for removal on the next reboot, and the user 
should be made aware of this. If the application is nm a second time before the next 
reboot, the system should rmain aware of the presence of the driver and not atte£q>t a 
second installation, waiting for tenmnadon to remark the coiq>onent removable at next 
reboot. 

It is important to diaractetize the base similarities and difierences, as fhey exist 
&r each device driver ckss, to ensure the present invention can correctly fm ftis 
not truly deshed to load and unload device drivers for system hardware that is constantly 
present. It ishould be understood diat alOtou^ this is not a preferred embodiment^in 
terms of programming ease, it is vAfbm the scope of the present mvention and may be 
required for specific reasons, such as the restriction in licenang agreements for 
applications that are delivered and run u^g the present invention. 

On non-Microsofi platforms, device drivers are typically handled very differently. 
Macintosh systems support both static and dynamic drivers, but they are all installed and 
removed through the same method, linldng with the Madntosli system folder will 
provide the necessary support For UNK systems, device drivers most typically require 
n modification to the running UNIX kernel, followed by a reboot! This process can be 
very conq)lex. hi the preferred embodiment, this process is automated; including 
resetting the kernel once the application is conq>lete. The gesaeral parameters of the 
process are the same as that described above for Wmdows applications, the actual process 
steps of compilation and persons &miliar wth such operating systems can carry oxst 
reboot. 
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Finally^ those of skill in the art vM imderstand that it is desirable to be able to 
recover and remove drivers across system Allures. Whatever data or processes necessary 
to retain system integrity are therefore a xnrefetred embodiment of the present invention. 
Those of skill in the art will also appredate tliat all types of device drivers might not be 
convenient]^ or efiELcieatly provided via the present invention, most particularly those 
associated yriik permanent hardware attached devices. 

OOnmER ITEMS 

In the present invention, it is recognized that there are several components of the 
invention, the behavior or presence of which is dUBFerent on alternate opiating systems. 
These con]ponents include fonts, processes, environment variables, and others. 

Some applications require fonts to be installed ia order to perform coixectly. Any 
fonts required will be specified in the Operating System Guard's configuration file. The 
Operating System Guard will enable these fonts prior to running the application and if 
necessary remove them afterwards. Most systems have a common area for storage of 
fonts in addition to a process for registering them or making tbe system aware of their 
presence, the Operating System Guard will utilize these available methods. 

On Windows, a font is copied to die WJNDOWSXFONTS directory. This 
however does not guarantee that the font is available to the running program. In the 
preferred embodiment, if the program uses the Windows API to access fonts, the font vwll 
need to be registered with a Win32 API call such as CreateScalableFontResource/ . 
AddFontResonrce. This will insert the font into the system font table. Once con5)lete, 
the Operating System Guard can remove the font with another appropriate API call like 
RemoveFontResource, then remove the file from the system As an alternate 
embodiment, the Operating System Guard could hook the API fimctions as described in 
the virtual registry method. In addition, the Operating System Guard can use its File 
subsystem to avoid placing the actual font file in the running system. 

On Maciatosh, the process is extremely similar and based on files in the 
Macintosh system folder and registration activation. On UNIX, however, the process is 
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dependent upon the application. Most typically, font lesources are added to the system as 
regular files re&olved in the proper location, so they can be accessed by name. With 
msaxy Motif systems, a font desci^tion needs to be placed into a font resource file, vMnAi 
ivill allow the font to be resolved. The Motif or X application can invoke the font either 
through the resolution subsystem or by a direct call Recently, many Motif and CDE 
based systems utilize Adobe scalable postscript fonts. These fonts need to managed 
through tiie Adobe type management system. There are exceptions, however, and as 
stated above, there are alternates to the Windows or other operating system default font 
management systems. Hie Adobe Type Manager provides some alternate inter&ces for 
tiiis process, as do other third party type management systems. In most cases it s3iould be 
decided whether to sq)port the interfice or ignore it. The purpose of Operating System 
Guard is not to provide a imiversal layer for all these systems, only to do soforthe 
operating system's own' subsystem 

Many applications require environment variables to be set This is most conunon 
. on UNIX systems, but is also heavily used by software, vAmii was oijginaify written on 
UNIX andportedtotheWindows operating systems, ^plications on the Windows 
(^erating systems heavily rely on the DOS PATH eoovironment variable and often set 
their own application specific entries. On the Windows 9x/Me environments, there are 
many environment settings, which are appficable as at its core is the DOS subsystem. If 
an application requires die presence of specific variables, or values to be set in existing 
. environment variables, the required environment variables will be specified in th^e 
Operating System Guard's configuratian file. The Operating System Guard will set these 
variables for the application's main process when it is launched As applications do not 
typically change environment settings as they operate, the virtual environment will not 
trap these calls, nor will it provide the iiill complement of fimctionality that the registry 
and configuration subsystem does. 

RECOVERY 

In some cases shown in the previous sections, actual modifications must be made 
to the operating system This is fiequent with device drivers and fonts. In addition. 
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changes can be made to the virtual envfronment that need to be persisted and available 
the next time an application is run. It is required that the Operating System Guard system 
be able to recover from changes to the system, removing the change from the ^stem at 
its earliest possible opportmiity. Alternately, ifthe system crashes daring an 
application's execution, the Operating System Guard ^ould track enough information to 
remove any change to the system if it is rebooted or otherwise, and should track the 
changes made to the virtual environment In the preferred embodiment, this is 
insplemented as a transaction bg, but can in other embodiments be done as some other 
similar component, vMch can be read on system startup so that dianges can be backed 
out 

CONTROLLING \lRTUALIZATION 

An inq^ortant a^ect of the invention relates to control of the miany ftcets of 
virtualizationvviuch the Olperating System Guard is capable o£ In the prefeired 
embodiment there ^dsts an instrumentation program able to ascertain the correct aspects 
of a software system to control Also included is a method to allow administrators and 
end users to view and modify those items to be virtualized by the system. 

In the automated program, the application to be controlled is observed in order to 
gauge the aspects of control The automated program is capable of performing this task 
during the installation process of the application, during run-time of the application, or a 
combination of botk In the preferred embodiment, the Operating System Guard is 
embedded ia a wrapper application. Post installation, or after one or many uses of the 
software, the wrapper application will query the Operating System Guard for a detailed 
list of all of it s actions. From this list of actions, the wrapper application wiH create the 
configuration files required to load and operate the Operating System Guard on 
subsequent uses. 

If used as part of the installation process, the Operating System Guard, in the 
preferred embodiment, will act as a virtual layer allowing the installation to be entered 
mto its environment only. After the installation, afl of the files, settings, et aL can be 
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duxDped for reload Jater. la tiiis way, the installatioii wiQl leave the original system intact 
and win have automatically created the necessary configuration files. When used during 
use of the application, the Operating System Guard is able to record either differential 
modtfilcatioiis to the eatvironment, or recodify the cohfiguralian fiOies. 

The Operating System Guard will pass its injEbrmation to the wrapper application 
fi>r post-jnroces^g. .£ithe prefecred embodiment, in addition to.the automatic entries 
that the system can create, -die wrapper application is programmed with operating system 
specific and application or domain specific knowledge. This knowledge is used to alter 
the output of the process to reflect known uses of configuration items or other entdes. In 
the preferred embodiment, a rules-based system is enq)loyed to con^are observed 
behaviors with known scenarios in order to effect changes to the coding. 

The wrapper application is also used as a viewer and/or editor for the 
configuration output of the process. This editor, in the preferred embodiment, enables a 
system administrator to add, edit, or delete items or groups of items firom the 
configuration. In observing the configuration through the editor, the administratar can 
also make rq>licas of the configuration, changing specific items as needed to effect 
appfication level or user custom changes. 

Referring now to FIG. 1, an embodiment of the present invention is illustrated 
fimctionally. In this embodiment, two sets of application/user data 60 are illustrated. 
The Operating System Guard 100 keeps the two instances of the application 50 firom 
interfering with one another, hi addition, as e7q)lained above, the operating system guard 
100 serves as an abstraction layer and as such collects commands and comnnmications 
between the application software 50 and the actual operating system 10 of the client 
conqputer. As illustrated graphically by the arrows, certain commands are between the 
Operating System Guard and the software application, this is in distinction to typical 
installations where these commands would iastead be acted upon by the opeiatmg system 
itself resulting in changes to the client conq;)uter that might not necessarily be wljat the 
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operator iatended Qa the other hand, other coBurmnds pass fhrough the Operatmg 
System Guard and are thea transferred to the Operatmg System itsel£ 

While this invention has been particularly shown and desciibed Tvith references to 
prefecred embodiments thereoi^ it win be imderstood by Aose skilled in the art that 
various dianges in form and details may be made therein iTsdthoTit departii^ fiom the 
scope of the invention enconqpassed by the appended claims. 
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What is claimed is: 

1. A system for creaitmg an application software eiiviromnent Tvithout changing an 
operating system of a client conq^nter, the system con^nsing an operating system 
abstraction and protection layer, Tvherdn said abstraction and protection layer is 
inteiposed between a nmning software qqplication and said operating system, whereby a 
virtual environment in which an application may nm is provided and application level 
interactions are substantially removed. 

2. Tie qrst«nofclaiml,vAerein changes directfy to the operating 
selectively made wilhin the context of the nmning application. 

3. The system of claim 2, vdiereia the abstraction and protection layer dynamically 
changes the virtual environment according to administrative settmgs. 

4. The system of claim 1, wherein the system continually monitors the use of shared 
system resources and acts as a service to apply and remove changes to system 
con^onents. 

5. The system of claim 1, wherein the operating system is a Windows-based operating 
system, and wherein all operations to the \Wndows Re^stry and .ini files are through the 
Wm32 API, the system further con5)rising a means for hooking functions, whaeby each 
time said iunc;tions are invoked another £mction or application intercepts the call 

6. The system of claim 5, A^erein the system hooks each appropriate API fimction to 
service a request A^diether mad^ by an application run from a server or if made by an 
applicatioh against a configuration key bemg actively managed 

7. The system of claim 1, herein said operating system abstraction and protection layer 
manages the integration of multiple instances of an application by recogmzing how many 
instances of an application are running. 
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8. The system of claim 7, ipvherein said operating system abstraction and protection layer 
avoids making changes on startup and shutdown imless there is only one appHcation 
instance numing. 

9. The system of claim I, wberein said operating system abstraction and protecdon layer 
preseaots an environment to an application that appears to be an installation enviro^ent 
vsdthout performing an installation, vAerehy a "pseado installation'* is created in which 
an of the settmgs are brought into a virtual environment at the time the appHcation runs. 

10. The system of claim 9, further conqprismg a means fin: preventing information on the 
client conqputCT fiona interfering or modifying the behavior of an application. 

1 1. The system of claim 9, fiither comprising a means for dynanncally changing the 
virtual environment according to administrative settings. 

12. The system of claim 9, wherein more than one instance of a smgle software 
applicatioja runs on the same client conQputer, and wherein each of said more than one 
instance connects to a different database 

13. The system of claim 12, \\^erem shared, controlled contexts are provided in which at 
least two of said instances of a single application share one or more virtual settings. 

14. The system of claim 1, fiurther corqprising a device driver monitor that receives 
instractions at the time of installation for a particular application. 

15. The system of claim 1, fiBrther conq)rishig a virtual Windows Registry con^onent to 
provide a ftll function registry to an application, but prevent modification to the 
underlying system registry. 
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16, The system of daitn 1, "n&erein the operadng system abstraction and protectioa layer 
responds with a key and its value if said key and value are stored within the operatmg 
system abstraction and protection layer, if aot stored, the operating system abstraction 
and protection layer allows the reqa^ to pass through to the Windows Regis^. 

17. Hie system of claim 16, \^^ein if an stteoapt is made to modify the value of said 
key, the operating system abstraction and protection layer allows the modification to 
occur to itself only. 
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